1. Field of the Invention
This invention relates generally to data processing systems and more specifically to methods and systems for controlling access to information and applications in such systems.
2. Background of the Invention
Many if not all installed computer systems contain information, applications and functions that must be restricted to access by particular subsets of users. Restricted access may take place at a number of levels. In one sense, the physical location of a computer terminal may form the primary basis for secure access to a computer system. If a user can not physically access a terminal, client or server (or path to any of the above) storing an application or data, the user will not be able to gain access to that desired application or data. While this level of security is important, the realities of the typical corporate environment necessitate further levels of security. This is because, in practice, all or most employees will generally have access to a physical link (i.e. terminal or client) to all applications, data and other resources resident on the corporate network.
As such, further security controls have been and continue to be necessary in order to allow controlled access to resources located on computer systems. Such controls are typically provided through software running on the computer system. Various levels of controls are provided. At the highest level, access to the computer network is typically controlled through a system user id (UID) and password. Thus, while anyone may potentially access the physical equipment providing a link to all available resources, only those that have been authorized through the provision of a UID and/or a password may "log on" to the system so as to access any resources available through the system. Access is generally provided through one or more security files (each associated with a resource or set of resources) listing the authorized UIDs and, if applicable, the passwords associated with such UIDs. As would be expected, access to these security files themselves is quite restricted. In most cases, however, satisfying the criteria necessary to pass a first level of security (i.e. entering a correct USD and/or password) will permit a user to access the system at an operating system level.
Once this has been achieved, the next level of security typically present in these systems is at an application level. Thus, after access at the operating system level, various applications will be presented to the user for selection. In a Windows 95/NT environment, for example, each of the available applications may be represented by an icon displayed on the desktop. In order to access any of these applications and/or the data associated with such applications, the user may need to have a second UID and/or password. In this case, the system will typically contain two separate security files; one for system access and one for application access. Alternatively, the user's system level UID and/or password may control access at the application level as well. In this latter case, there may be two different security files (one controlling system access and the other controlling application access) present on the system, both of which would contain the same UID and/or password corresponding to a user which has access to the particular application and/or associated data.
An additional level of security which is often provided occurs within a particular application. Thus, for example, a user with access at the system level and at the application level may, nevertheless, be restricted as to what functions he or she can perform within a particular application once access to that application has been granted. A user may also be restricted from accessing particular data associated with an application even though the user has access to the application. Security files similar to those described above and associated with the specific applications are used to control this process. In this case, application level security is maintained at the file level. A user with access to a database program may be restricted with respect to particular data associated with the database application. For example, it may be that a particular user/employee in the human resources department might have access to a compensation database while that same employee would not have access to a manufacturing parts database.
In most cases, especially in the case of medium and large network systems, one or more individuals are tasked with administrating the operation, maintenance and configuration of the corporate data processing system. Such individuals are referred to herein generically as administrators by virtue of, among other things, their heightened security privileges with respect to security files and other administrative resources. Often, one or more administrator(s) is/are responsible for maintaining the above described security files as well as other matters in connection with controlling access to system resources. In current systems, however, the administrator's tasks are difficult and time consuming for many reasons.
First, the addition and deletion of employees as employees are hired or leave requires constant attention to the security files on an ongoing basis. This can be a time consuming process in that an administrator must typically access security files directly and manually manipulate them to reflect the current state of privileges with respect to system resources. Second, because large systems often contain multiple applications, multiple databases, multiple files and even multiple operating systems, each time a new user is added or deleted, a significant number of security files must be updated for each user addition/deletion. This can be very time consuming and is prone to a number of errors. Perhaps more significantly, new users typically experience a significant lag time before the administrator gets around to updating security files to give the user the specific access authorities to which the user is entitled.
Another problem with existing security administration is the fact that administrators must have specialized knowledge in order to be able to make the required changes as new users are added to the system, as existing users are deleted from the system or as security privileges change due to, for example, job function changes. For example, in order to effect a security access change in the typical corporate environment, an employee must have his or her manager fill out a form for the manager's signature. Once this is done the form must be routed to the appropriate administrator for manual and time consuming updates to, in most cases, multiple security files. Until this process is completed, the user can not exercise his or her new security access rights.
One particular way in which system developers and system configurers have attempted to deal with many of these problems is to severely limit the number of separately controllable categories of access rights. For example, rather than providing a separate bundle of rights for a particular job position, systems are often designed where many jobs are bundled together such that all jobs in the bundle have the same rights. In an extreme case, all users of the system be provided with access to all resources available in the system. While this is relatively easier to administrate and maintain (since less updates need to be performed and less security files exist) the security in such a system is often less than satisfactory.